Maintaining a safe network environment can be a challenge in today's ever-growing virtual environment. To ensure that the network is fully functional and secured, companies may implement monitoring and filtering arrangements. Monitoring and filtering may help ensure reliable operation while mitigating potential malicious activities.
To facilitate discussion, FIG. 1 shows a simple legacy network environment with a tap arrangement. A network environment 100 may include two networks (102 and 104) connected via an interconnected network 106. Consider the situation wherein, for example, a user connected to network 102 may be sending an email to a user on network 104. The email, in the form of a set of network packets, may be routed through the network via a plurality of routers (108, 110, 112, 114, 116, and 118) and/or switches (120 and 122).
In a legacy network environment, network elements (such as routers and switches) may route or switch network traffic packets through the network based on their IP addresses and MAC (Media Access Controller) addresses. For example, a data packet being transmitted may be sent to router 108. Upon receiving the data packet, router 108 may employ the IP addresses in the packet header to determine the source and destination addresses for the network traffic packet and forward the network traffic packet to the next network element (“hop”) based on the IP addresses. Since routers tend to be layer 3 devices, router 108 may modify the MAC address before sending the data packet to the next hop (e.g., network element). In an example, router 108 may change the MAC address by modifying the source MAC address to its own MAC address and the destination MAC address to the MAC address of the next router (such as router 110) in the path. Unlike routers, switches are usually layer 2 devices that do not tend to modify the source and destination MAC addresses of the data packet. In an example, if switch 120 encounters the data packet, the data packet may be forwarded, based on the current MAC addresses, without being modified.
To monitor network traffic, taps (128, 130, 132, and 134) may be employed. The network traffic being monitored may be copied and redirected to monitoring tools (142, 144, and 146) via a network packet broker 140. In a typical network environment, each tap is associated with a receive port of a network packet broker. For example, receive port 1 of network packet broker 140 is associated with tap 128, receive port 2 is associated with tap 130, receive port 3 is associated with tap 134 and receive port 4 is associated with tap 132. Based on this association, network packet broker 140 may be able to deduce that the data packet being received at port 1 have been forwarded by tap 128.
The monitoring tools may access relevant, data in the duplicate network packet and depending on the data obtained from the duplicate network packet, the monitoring tools may perform various tasks, such as maintaining the stability of the network, preventing malicious attacks, etc. For example, the location of the sender and the receiver of the data packet may be determined based on the source and destination IP addresses. Also, the source and destination routers may be determined based on the MAC addresses. Further, the tap that duplicated the data packet may also be determined based on the receive port identifier since each tap is associated with a specific port of network packet broker 140. In addition, network packet broker may add a time stamp to the duplicated network packet before forwarding the data packet to the monitoring tools. With the time stamp, the monitoring tools may be provided with a time approximation of when the tapping may have occurred.
The example as shown in FIG. 1 is an example of a network environment in which each tap is physically wired to a network device within the network. However, in recent years, the popularity of the Internet has given rise to new network architectures that may not always entail physical connections. Instead of typical network elements hardwired to one another, the new network architectures may include a partial or full implementation of a virtual network, in a virtual environment, such as cloud-computing network or mobile network, network data packets may be flowing through abstract representations of the actual physical hardware.
In a virtual environment, especially one that is heavily dependent upon layer 2 network elements, monitoring network traffic may be challenging. First, since most layer 2 network elements, such as switches, are configured to forward data packets without modifying the MAC addresses, the source and destination MAC addresses no longer provide the required data necessary to track the previous network element and destination element of the “hop”. Thus, if a problem is identified in the packet data, the monitoring tools may not have the required data necessary to perform analysis and determine the source of the problem.
Second, the IP address, especially the source IP address no longer refers to a physical location. In the legacy hardwired network environment, the IP address may refer to a stationary network element. However, given that IP address may now be associated with network devices (such as mobile devices) that are not necessarily stationary, the IP address may no loaner refers to the location of the mobile device. For example, a virtual machine or a tablet may be associated with a first IP address. However, even if the tablet roams to a location fifty miles away from the location where the first IP address is initially assigned to the tablet, the tablet's IP address would still stay the same while roaming to this distant location. This is necessary for session continuity and is well-known. Thus, determining the source of the problem may be a challenge for the monitoring tools since an IP address is no longer a reliable indicator of physical location.
Another challenge is that tap devices may no longer be directly connected to a network packet broker in a virtual environment. As a result, upon receiving a network packet, the network packet broker can no longer determine the identity of the origin of the tap device since the tap device is no longer physically associated with a particular port of the network packet broker.
Similar to the legacy hardwired network environment, the network packet broker may provide a time stamp for the incoming network packets. However, the time stamp is the time at which the network packet broker receives the network packet. The time stamp is not the actual time that the tap duplicates the network packet. In today network environment, wherein time accuracy may be required in order to determine when and where the problem may have occurred or to ensure accuracy in financial transaction for example, time estimate may no longer be sufficient in enabling a timely response.
Accordingly, arrangements and methods for performing network monitoring on a virtual environment are desirable.